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OP1TMIZA1TON OF CHANGE LOG HANDLING 

CROSS-REFERENCES TO RELATED APPLICATIONS 

This Application for Patent claims the beitefit of priority ^ and hereby 
incorporates by reference the entire disclosure of, oo-pen&xg US. Provisional 
5 AppKcations for Patent Serial Nos. 60/108,902, filed November 17, 1998, and 
60/H0.485, filed December 1, 1998. This Application for Patent is also related by 
subject matter to co-pending US. Ncmprovirional Application for Patent Serial No. 
, filed an (Attorney Docket No. 346S0-0O4G2). 

BACKGROUND OF THE INVENTION 
10 Technical Field of the Tnv^ffrr, 

The present invention relates in general to die field of ccinmumcatioss,asd 
in partf cttlar, to optiimaang 6y^^ 
fiia^maeaseeffideiKyofmfQr^^ 

Descrintion ofn^fM 

15 Handheld orgamzers, such as personal digital assistants, have become 

increasingly popular in our modem, mfonnalion-rich society. These small, portable 
devices enable uses to conveniently store andtnaffltamsu^mfimnatimaswmtacts, 
phone books, calendars, task Esta, etc and allow users to synchronize the stored 
information witha simil^ 

20 enndatesteapjmJiHiatehard^or» The^JmwszRrUmprecea 
allows users to add, modify or delete rnfonnRtinn at a first device and gyn* 
added, modified or deleted information wkh a secona device so thai both devices 
contain the same infonrafaon. With the recent incorporation ofhandheM m^n;^ 
or at least features thereof, into wireless wramiimication devices, such as mobile 

25 phones md pagers, and the addition of wireless interfeces to conventional handheld 
organizers, the syndmmization process has become easier and more convenient by 
allowing b.«s* to synchronize information stored at associated devices via e wirefcss 
interlace 
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10 



The convenience and efficiency of information synchnmizatton has been 
further enhanced through the use of change log handling. A change log is typically 
a «£k»Ua oi e>uup uf ramus which siorc a iog of changes made to one of the 
associated databases. For example, achange log associated with a first database stores 
and maintains intonation associated with changes made to records of the first 
database. During a s ynchr o ni za ti on procedure, the change log is utilized by a 
synchronization apparatus to process only those changes that are contained in the 
changelog. Consequently, the change log significantly increases the efficiency of 
infbnnation synehxoiiization by avoiding the necessity of comparing each record 
wntairiedmthe first database wim 
databases order to inaiiriato a 

One significant problem associated with this ar^mjach is that the change log 
is stored and manned cmty at the . 
apparatus to request a transfer of the airire change log m response to 

15 synchronization nnjcedwrR BecmiM! the syn&xvisx&xa. eppsstez sssst process 
changes at fee second database in the same order in which the rfig q ^y^ mn^ fp 
the first database, the synchronization apparatus must read the entire change log to 
identify the oldest entries of the change log (eg., the oldest changes of the first 
database). This prc<»dure can be time-consuming d 

20 log. 

Another significanl problem is that existing approaches da nni H ? qrw hf>w the 
change tog shouMbeoptmiatytr^^ 

m wbich the change tog should be optimally processed by the E^Ttdrroarzation 
apparatus, and howthe sywdnioriization apparatus should proceed when an interruption 
2S occurs during the transier of the change log. For example, a typical transfer begins 
with the first byte of the change log, and ends with the last byte of the change log. If 
an mterrupn'on occurs during the transfer, the synchronization apparatus will not 
receive the oldest entries of the change log, and it therefore cannot begin processing 
the entries of the change log at the second database. Consequently, an mternrption in 
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the transfer of the change log forces the srynchrmrization apparatus to request 
transmission of theerJzrechange log after aconncction to the first database is restored 
Twa ptoccdiire fimher decreases the efficiency of information synctamization. 

Therefore, in fight of the deficiencies of existing approaches, there is a need 
for a method and apraralust^ 

a change log to thereby increase the efficiency conformation syncrmmizati 



aon. 



SUMMARY OF THE INVENTION 

The deficiencies of the prior art are OTercorneby the method and system of the 
present inventioa For example, as heretofore unrecognized, it would be beneficial to 
optirruMirrfonrufflOT 

tocreasir^fceeffidew^^ Forexarrn>le > maccordariMwh^cme 
aspect of the present invention, the second device stores a change counter value 
associated with a last syncibionized entry of a change log stored at the first device. A 
porrion of t>w rhan^ Jogwctdnins eztrjec st^rsirg s^asrJjsjiGfid diange couuto 
15 value is preferably transferred from the first device to the second device hi a 
predetermined order so as to avoid restarting the synchroruzarion procedure in the 
eventmmterniptionmtriet^^ AIsc^ the change counter 

value stored at the second device is preferably updated after each entry of the 
transferred change log is processed at the second device arid m response to database 
20 updates performed at the first device. 

InafirstembodSmeir^acuiTrat^ 
. isT^tedatthefh^devicemres^^ 
device. The first device then retun»theiari^charigeroun^ 
m response to a processing condition resulting from the database update mr, mm A a » 
25 the first device. The updated change counter can be included in, for example, a 
confirmation message to the second device. The wmfmnarion message can inform the 
second device of the current change counter, the unique identification (TJID) of the 
record at the first device and a status of the database update command. The second 
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device may thai store the returned change comer far use in a subsequent 

sj!H±ronizationpro 

having to read the entire change log. 

Ih~A second embodiment, the second device submits a stored change counter 
5 to the first device b response to initiatira 

device transfers to the second device entries of the change log occurring after the 
submitted change counter. The entries of the change log are preferably transferred to 
the second device in reverse order(e.g., with the oldest entries of the 
The second device also prefer 
10 and updates the change counter stored at the second device after each entry is 
processed. As a result, fee second device can avoid restarting the synchmrazation 
procedure in the event an mtemrption occurs, and can start pe rformin g updates in 
accordance with the received entries of the change log, even though only a portion of 
the transferred change log is actually received. 
15 Ths tedsics] 2dv*2i2g2c of a^pro^s^sEtioik include, 1h*1 are not limited 

to, the following exemplary technical advantages. It should be understood that 
particular embodiments may not involve any, mnch leas all, of the following 
exemplary technical advantages. 

An important t ec hnical advantage of the present invention is feat it increases 
20 the efficiency of change loghandEirgby ensuring that the second device maintains the 
current change counter. 

Another important ftr t ni c al advantage of the present invention is that ft 
enables the second device to process change leg entries dt^ite an inte/n^tio^ 
transfer of the change log. 
25 Yet another important technical advantage of the present invention is that it 

allows the second device to begin processing the change log even when only a portion 
of the change log is actually received 
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Yet still another important technical advantage of the present invention is the 
ability to improve the efficiency ofsynchixniization procedures which utilize a change 
iog by opnmazmg cnaqge log Handling. 

The above-described and other features of the present invention are explained 
5 in detail hereinafter with reference to the illustrative examples shown in the 
accompanying drawings. Those sldlled in the art will appreciate that the described 
embodiments are provided for purposes of illustration and understanding and that 
numerous equivalent embodiments are contemplated herein. 

BRIEF DESCRIPTION OF THE DRAWINGS 
10 A more complete understanding of the method and system of the present 

mventionmay be had by reference to the following detailed description when taken 
m conjunction with the accompanying tlinw ^g? wherein; 

HGUKE1 ittostnatesane^ 
s^Tidradzrs informal 
15 of associated devices; 

FIGURE 2 illustrates an exemplary functional block diagram of a 
synchronization apparatus that can be used for synchronizing separate ffat^K a^^ and 
FIGURES 3 A, 3B, 3C and 3D illustrate an exemplary method in flow chart 
form by which the principles of the present invention may be advantageously 
20 practiced. 

DETAILED DESCRIPTION OF THE ElUV/INGS 

In the following description, for purposes of explanation and not limitation, 
. specific details are set forth, such as particular circuits,, logic modules implemented 
in, for example* software, hardware, firmware, some combination thereof, etc,), 
25 techniques, eta in order to provide a thorough understanding of the invention. 
However, it will be apparent to one of ordinary skill in the art that the present 
invention may be practiced in other embodiments that depart from these specific 
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details. In other instances, detailed descriptions of well-known methods, devices, 
logical code (eg, hardware* software, firmware, etc), etc are omitted so as not to 
obscure the riescnpuonott&ep 

A preferred embodiment of the present invention and its advantages are best 
5 understood by refei^ 

for like and corresponding parts of the various drawnjgs* It should be emphasized thai 
although the Allowing description describes certain aspects of the present invention 



m Uio waicu ox luiurtnouon synccroinzanQn Between associated wireless devices via 
a wireless interface, the present invention is not limited to such devices or interfeces. 
1 0 Rather, the principles of the present invention are equally applicable to information 
synchronization between other types of devices via, for example, electrical or electro- 
mechanical connectors* Therefore, the following description is provided for purposes 
of explanation* and not limitation. 

Referring to FIGURE 1, an exemplary block diagram of a wireless system 

plurality of associated devices is illustrated generally at 1 0. Hie exemplary wireless 
system includes a first device, such as a wireless handset 100, which is capable of 
communicating with one or more associated devices, such as another wireless Hands^ 
1 10, a personal computer (PC) 120, a personal digital assistant (PDA) 125, a pager 

20 130, and a car cradle 150. Bach of the associated devices 1 1 0, 120, 125, 1 30, and 1 50 
may also communicate with one or more devices in addition to the first device 1 00. 
For example, fee personal computer 120 may communicate with the pager 120, and 
tfcspagcr 120 m^fethcr communicate with anotherpager 140, The devices depicted 
in FIGURE 1 preferably communicate with one another over a wireless interface 1 60 

25 using, for example^ infrared transceivers or short range radio transceivers. 

Each device 100, 110, 120, 125, 130, 140 and 150 farther includes a 
corresponding database (not sfcown m FIGURE 1 ) which stores information, such as 
phone books, calendars, tasks lists, etc By Bynch mnrang foe pqinratE databases using 
an appropriate synchronization protocol, information stored at each device may be 
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synchronized so that each device contains (he same information (e.g., changes made 
to entries or records in one database are also made to fhe other databases). 

Referring to tliJUKJd 2, an exemplary functional block diagram of a 
gyachroniyatira apparatus fliat can be used for synchronizing separate databases is 
5 depicted generally at 20. This exemplary apparatus includes a synchronizatio 

engine 2 1 0 connected to and associated with a particriar(5>ric engine) database 200. 
Far example; the sync engine database 200 can be a database associated with, or 
included as part o£ the wireless handset 100 shown in FIGURE L In this context, a 
"sync engine" is preferably the software thai performs the database synchronization 
10 Amotion. However, an appaia tus that performs sync engine fractions can also be 
considered as part of the sync engine 210. A second device database 230 is to be 
synchronized with the sync engine database 200. For example, the device database 
230 can be associated with, or included as part of; the FDA 125. Notably, the 
synchronization procedure can be performed in either direction. For scaniplei the 
IE PDA 125 ccs g?ss mcludc a sync zagnz 210, thereby aUcwiag a device tetsfoaa* 230 
associated with the wireless bandit 100 to be synchronized with a sync engine 
database 200 associated with the FDA 1 25 , 

A gynrftmniratirm pmtnral 2?.Q is used tn define thft database fiynghrnriignlirm 
procedure* A change log 240 is preferably associated with the device rfatahnsn 230, 
20 and is preferably a log or register in which changes made to the device database 230 
are temporarily stored. For example, the size of the change log 240 can be fixed* and 
cilder changes can be pushed out of the change log 240 as new changes are added- As 
such, each gaty in the change leg 240 is associaTr/l wi th a certain act pgrfpuned on 
the device database 230 (eg., add, delete, or modify), a time stamp (or change counter 
25 value) and a Unique Identifier (UID). AUTO is a number assigned to each twenty 
in a database. These UID numbers are unique in that they are not reused within the 
same database. Preferably, the change counter is stored in the change log 240 for each 
change that occurs, and also stored in the sync engine 210 after a synchronization 
procedure is performed 
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In synchronizing information between the sync engine daiabas e 200 and the 
device database 230, (he sync protocol 220 typically performs either a "slow" 
aynciifoni2arion or a "iasr syne tfironTOrtio n. If at least one of tire two databases 200, 
230 contains information when the first synchronization attempt is a slow 
5 synchronization procednre is performed. Slow synchronization is a procedure 
whereby all of the cotries in one of the databases are compared with al] of the entries 
iq the associated database, Xndzvidnal entries are then added, modified or deleted in 
ader to maintain a one-to-one relationship between the two databases 200, 230. 
When such a slow synchronization procedure is performed, a UID resolution table is 
10 created (eg., by the sync engine software). The entries in such a UID resolution table 
reflect the relationship between the entries of the two databases Oat have been 
synchronized. For example, if therein aTJID for an entry m th<? ripyjcft data ba s e 23Q y 
the UID resolution table provides the UID for 

the UID of fiat same entry in the sync engme database 200. In contrast, a fist 

changes since the last synchronization was performed (eg., no entries in the change 
log 240 have been pushed out). When such a fist synchronization procedure is 
performed, only those unsynchromzed changes in the affected database have to be 
compared and transferred between the device database 230 and the sync engine 210. 

20 Accordingly, fist synchronization is significantly faster than slow synchronization. 

One significant problem associated I with the synchronization apparatus 20 is 
(hat the sync engine 210 may not know the value of the current change counter, 
because both the chaegs counter and the UID asscciaiad with &ht database record are 
created in the device database 230, not the sync engine 210. For example, when the 

25 . sync engine 210 performs database updates on the device database 230, the sync 
engjne210wiU not know the valueoft^ One technique that 

may be used is to return the UID of each new entry after the entry is added to the 
device database 230 as a confirmation that the new ratry was received and processed 
at the device database 230. .The change counter, however, is not returned. The 
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disadvantage with fids technique is that the sync engine 210 must read the whole 
change log 240 after a complete synchronization is performed in order to determine 
the current change counter* This proces can be time consomi^ 
of the change log 24& 

5 Another problem arises when the transfer of the change log 240 from the 

device dat a b ase 230 to the sync engine 210 is interrupted For example, a typical 
transfer may start from the beginning of the change log 240 and end with the last byte 
of die change log 240. As a resold if an interruption occurs during die transfer, the 
sync engine 210 would not receive the last exdxy in the change log, and therefore, not 
10 the oldest entry of the change log. Consequently* the sync engine 210 cannot start 
processing the change tog 240, Off 

ha sco gnp tetdyreread die change log240 afteraconnectionis restored. This increases 
the inefficiency of change log handling. 

RefemxQtonGUIU£3A,3B,3Cax^ 

15 fb^n by TO&ch the principles of the present urraiii&ii ^vttnfogeouz^y practiced 
is illustrated generally at 30, It should be noted that the exemplary method described 
herein can be implemented by, for example, the exemplary synchronization apparatus 
depicted in FIGURE 2 and/or the exeinplaiy system dqweted in FIGURE 1. For the 
purpose of illustration, and not limitation, the following description describes the 

20 exemplary method in the context of database syndnomzation between a sync engine 
database 200 and a device database 230. These databases 200, 230 can be contained 
in, or associated with, one or more of the devices depicted in FIGURE 1. The 
exemplary method, however, 2s not limited to these specific devices. Rather, persons 
of reasonable skOl will recognize that this exemplary method is equally applicable to 
' 25 other implementations that depart torn the specific details describedhereirL It should 
be further emphasized that the method can he performed in either direction (e>g., die 
device database 230 can include a sync engine 210 wHdi can be used to synchronize 
information between the device database 230 and the sync engine database 200 in 
accordance with a change log 240 associated with die sync engine database 200). 



PAGE 74/109 * RCVD AT 7/19/2M5 5:57: 1 8 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-6/27 * DNJS:2738300 * CSID: * DURATION (mm-ss):23K56 



Jul. 1 9. 2005 3:14PM Vierra Magen LLP 



No. 3254 P. 13/47 



WO 00/29998 PCI75E99/02004 

-10- 

Refening to FIGURE 3A, the exemplary method begins at step 300 with the 
sync engine 210 requesting a serial number ftom a device d* ttafr a sg 230 in 
communication therewith. This request can be mftrat^H by; for example^ receipt of a 
paging signal or an acknowterigrnRnf signal from the device datable 230. In response 
5 to the serial number request, the device database 230 returns its o**^*tH serial 
number to the syirc engine 210 at step 3 10. This associated serial number preferably 
uniquely identifies the device database 230, and can include, for example, aBlnetoofh 
ID or an identification a sso c i at ed with another communications protocol. The sync 
engme210tben compares the received serial nnmbertoastored list ofknown devices 
10 atstep320tod£tomm£wheth&thed thereby indicating that a 

Gist synchronization is requested. 

If sync engine 210 determines that the device is a new device (e.g., that a first 
synchronization is requested), the process proceeds to step A where a slow 
synchronization is performed. Referring to FIGURE 3B, the sync engine 210 
15 pei'ihnuS the slow syr^hrorriTatioa procedure by Hurt iequt=Uiug tiie cixureoi change 
counter (CC> from the device database 230 at step 330. In response to this request, the 
device database 230 returns the current change counter, and the sync engine 210 
temporarily stores the returned change counter value at step 34Q. Hie sync engine 210 
then requests all database records of the device database 230 at step 350, and the 
20 device ^aKag<% 230 returns all its records to the sync engine 210 al step 360. The 
sync engine 210 then performs a slow synchronization procedure at step 370 by 
comparing all records received from the device database 230 with records stored at the 
sync engine database 200. Ibis step of comparing is performed on a field-by-field 
basis so that a onc4o-one relationship between the device database 230 and the sync 
25 engine database 200 is maintained. After the slow synchronization procedure is 
completed* the sync engine 210 stores the current change counter at step 380 which 
is then utilized in subsequent synchronization procedures as will be described in 
greater detail .below. 
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Refemngback to step 320 of FIGURE 3A, if the syne engine 210 determines 
that the device is not a new device (e.g_, thai a first syndmmization has already 
occurred), the process proceeds to step B where the sync engine 210 initiates a fast 
synchronization procedure as illustrated in FIGURE 3C. In this ^synchronization 
5 procedure, the syne engine 210 submits its stored change counter to the device' 
database 230 and requests from the device database 230 at step 390 the entries of the 
change log 240 that occurred after the submitted change counter. If the device 
database 230 deteimmes at step 400 that sU 

change log 240 (e.g, none of the entries in the change log 240 thai occurred after the 
10 submitted change counter have been pushed out), the device fofrba sc 230 returns at 
step 4 1 0 the entries of the change tog 240 that occurred after the submitted change 
counter. Preferably, the device database 230 

with the oldest entries first) so that if mintemrption occurs during tran$mi$sxan of the 
entries of the change log 240, the sync engine 210 may begin processing the change 
IS log 240 for at lease [he erodes that are received Otherwise, an inraruprion in 
transmission would force the syne engine 210 to reread the change log 240 when a 
connection is reestablished in order to receive the old^unsyndiromzed entry of fiw 
change log 240, 

At stq> 400, if the device database 230 determines that not aUunsyndmjnized 
20 changes are present in the change log 240 (e,g., some of the entries in the change log 
240 occurring after the submitted change counter have b een pushed out), the device 
database 230 returns a "too many changes" indication, such as an to die syne 
engine 210 at step 415. Tuis "too many changes 41 indication notifies ihe sync engine 
210 that a fast synchronization procedure is not possible, and that an alternative 
25 procedure mustbepecfbnned Accordingly, the syncengine210 inspects the returned 
change log at step 420 to determine whether aUth^ If so, then the 

sync engine 21 0 determines at step 430 whether the returned change log is empty {e.g., 
no changes were made to the device database 230 since the last synchronization). If 
the returned change log is empty, the process proceeds to step C as illustrated in 
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F1GURE 3D. Otherwise, the sync engine 210 requests database records from the 
device database 230 in accordance with the entries contained in the returned change 
log at step 440- The device database 230 returns the requested records at step 4S0. 
The sync engine 210 performs a database update to the sync engine database 200 in 
5 accordance with each returned entry of the change log and each returned record, and 
increments the stored change counter at step 460 after each entry of the returned 
change log is processed. Hie sync engine 210 repeats steps 44&460 for each entry 

coptamcrf in tha mtimigrf cfamga wntft tha gyrws gnging 91 n rf-twmWo iW a T1 ffr* 

changes ate processed at step 47a The process then proceeds to stepC as illustrated 
10 in FIGURE 3D. 

It should be noted that in a preferred embodiment of the present invention the 

sync engine 210 processed the returned change log in reverse order (ag., with the 

oldest entries of the change log first) and updates or increments the change counter 

stored at the sync engine 210 afler each en^ 
IS Hiis <£i&bka the sync engine 21C lb keep track uf tiie outran change counter so thai 

if there is an interruption mttffl)Sroi$$iOtt<rf<te 

occurs, the sync engine 210 can begin processing fixe change log in accordance with 
the last updated change counter value* Consequently, the sync engine 210 can avoid 
restarting the synchnnazafaon process Furthermore, if the device 

20 database 230 transfers the entries of the change log 240 with the oldest entries first at 
step 41 0, the sync engine will always receive a valid portion of the information and 
may advantageously begin processing the returned entries* even though the transfer 
is interrupted and onjy a pardon of the entries is received. 

Referring back to step 420 ofFlGURE 3C, if the sync engine 210 determines 

25 that 'too many changes" occurred, the sync engine 210 performs a k sexnH8ilow M 
synchronization procedure. This procedure begins with the sync engine 210 
requesting all database records from the device d atabase 23 0 at step 48 0, The device 
database 230 then returns all of its database records (preferably oldest records first) to 
the sync engine 210 at step 490. At step 500, the sync engine 210 compares the UlD's 
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of the returned records with the UID resolution table stored at the syce engine 21 0 in 
order to process any differences between the device database 230 and the sync engmi* 
database 200. This process is significantly more efficient than performing a slow 
synchronization procedure. The sync engino 210 then requests the change log 240 
5 from the device databascat step 510, and updates the diange counter stored at the sync 
engine 210 at step 520 in accordance with the most current entry of the returned 
change log 240. The process then proceeds to step C as illustrated in FIGURE 3D. 

At step C changes made to the sync engine database 200, if any, are 
synchronized with the device database 230. Accordingly, the sync engine 210 
10 determines at step 530 whether any changes were made to the sync engine database 

200. Tf vifit ihei pmrahrre ts mrnplet^ md the gyrichmnimtinn pmrariiire termmntwa 

If changes were made, the sync engine 21 0 "fcjats" changes to the device database 230 
at step 540. This step involves the sync engine 210 issuing a database update 
command (e.g* a "put* command) to the device database 230 telling the device 

IS iWrfifon 23C u> iiidkd Miaui diangea to lis datebaafc leuuds* sucu as adding * raw 
record. Upon successful completion of the database update command, the device 
database 230 updates the change log 240 byaddhl g at step 550 the associated database 
action (e,g,, add, modify, delete), the UID of the associated database record and the 
updated (or incremented) change counter. At step 560, the device database 230 returns 

20 a confirmation message which includes, for example, the status of the database update 
command ok or error), the UID of the associated database record, and the 
updated value of the change counter. The sync engine 210 at step 570 then updates 
its stored change counter in accordance wiih the returned change counter. It should 
be noted that the device database 23 0 preferably returns the current change counter, 

25 regardless of whether or not the database update command is successfully processed 
or not The returned change counter enables the sync engine 21 0 to maintain the most 
current change counter for use in a subsequent synchronization procedure or in the 
event an error occurs during the processing of the change log . The sync engine 210 
repeats steps 540-570 for each change of the sync engine database 200 as indicated by 
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the afGnnative^ea^ositive branch of the derision step 580. Once all changes are 
processed, the synchronization procedure is complete, and the process terminates. 

Although preferred embodiments) of the method and system of the present 
invention have been illustrated in the accompanying Drawings and described in the 
5 foregoing Detailed Description, it will be understood that the present invention is not 
limited to the embodiments) disclosed, bat is capable of numerons rearrangemaBs, 
modifications, and substitutions without departing from the spirit and scope of the 
present inventi on as set forth and defined by the following claims. 
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WHAT IS CLAIMED IS; 

1. A method for optimizing chan^ 
the steps o£ 

storing a change counter at a first device; 
5 updatn^fhe change comite 

rctnnnng the updated change counter to the second device in response to a 
processh^ condition result^ 

2. Themethod for optimizing changed 

10 step of returning comprises returning the updated change courier m a con&tnation 

m e ssa ge to the figflonri jte^Fwi 

3« Tnemeuiodfaroptt^^ 
confirmation message further inc^^ 
of the first device and a status of the database update command. 

15 4. Themethodforopthmzmgd^ 1, whexemtfae 

processing condition comprises at least one of successful completion of the database 
update ff o i mp*rc^ ffli^ termi ?*^ of Hie database update coinr p^ 1 *^ 

5. The method for optimizing change log handling of claim 1, further 
comprising the step of updating a second change coimtcr stored at the secoiridevre 

20 in accordance with the returned updated change counter from the first device. 

6. The method for optimizing change log handling of claim 5, further 
comprising the steps of: 



PACE 80/109 * RCVD AT 7/19/2005 5:57:18 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-6/27 * DNIS:2738300 * CSID: * DURATION (mm-ss):23^56 



Jul. 1 9. 2005 3:15PM . Vierra Magen LLP 



No. 3254 P. 19/47 



WO PCT/SE99/&2004 

-16- 

the second devke submitting the second cl^^ 
response to initiation of a sjaichronization procedure; and 

the first device transfaring to the second device entries of a change tog 
occnzring after the submitted second chaz^gs counter, the entries of the change log 
5 transferred to the second device with oldest entries first 



7. The method for optimizing change log fi Trifling of claim 6, farther 
comprising the steps of: 

the second device processing the transferred entries of the change log with the 
* oldest entries first; and 
10 the second device updating the second change counter after each entry of the 

transferred change log is processed. 

& The method for optimizing change log handling of claim 7, further 

the second device resubmitting the second change counter to the first device 
is if there is an interruption in transfer of the entries of the change log; add 

the first device transferring the entries of the change log occurring after the 
resubmitted se con d change counter* 

9. Themethodfbroptimizing 

first device comprises a device database and to second device comprises a software 
2 0 synchroni2azk>n engine. 

10. The method for optimizing change log handting of claim 1, wherein the 
fiist device comprises at least one of a wireless handset, a c o mputer , a personal digital 
assistant (PDA), a pager and a car cradle. 
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11. Ttemethodfooptfanizmgcha^ 1, herein the 
second device comprises at least one of a wireless handset, a computer, a personal 
digital assistazit (PDA), a pager mid a wcifidle. 

12. A method far increasing efficiency of information synchronization 
5 between a first device and a second device, the method comprising the steps o£ 

staring a first change counter at the first device; 

updating the first change counter at the first device in response to a database 
update command from the second device; 

retooling the updated first change comxter to the second device in response to 

10 ft ptPCTSSlUg CM^tti/m r ^ gn ^ r> g %n rtataKagfs npflnle emnmand flt the first dgvicg; 

rj ^qtfng a second change counter stored at the second device in accordance 
with file returned updated first change counter; 

the second device submitting the updated second change counter to the first 

15 the first device transferring a portico 

portion of the change log containing a log of changes to a database associated with the 
fiist device occurring after the submitted second change counter, the portion of the 
change log transferred to the second device with the oldest entries first; 

the second device processing the portion of the change log with oldest entries 

20 first; and 

the second device update the stored second change counter after each entry 

is 

of the portion of the change k>g is processed. 

13. The method for increasing efficiency of synchronization of information 
between a fiist device and a second device of claim 12, wherein the step of returning 

25 comprises returning the updated first change com 
second device. 
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14. The method for increasing r.ffiriency of gypchmrrizarion of information 
between a first device and a second device of claim 13* wherein the confirmation 
message further includes a Unique Identifier (UID) associated with a debase record 
and a status of toe database iqxtate command. 

5 15* The method fcrincreasing efficiency of 

between a first device and a second device of claim 12, father comprising the steps 
ofi 

the second device resubmitting the second change counter to the first device 
if there is an interruption in transfer of the portion of the change log; and 
10 the first device transferring fixe portion of the change log occurring after the 

resubmitted second change counter. 

16. The method for optimizing change log handfo^ 
the second tfevlce coaptiacs a bufiwatc gyiickoaiyjiiian engine; 

17. A system for optimizing information synchronization between a fiist 
15 device and a second device, the system comprising: 

a fust database having a change log associated therewith, the change log 
including a change counter associated with each change performed on the first 
database; 

a second database associated with fee first database; and 
20 a synchronization engine associated whh the second database adapted to 

synchronize information between die first database and the second database, the 
synchronization engine adapted to issue a database update co m m and to the first 
database to B^^t for changes to the second database, the synchronization engine 
receiving an updated change counter from the first database in response toaprocessing 
25 condition resulting from the database update command at the first d at a ba se. 
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18. The system for optimizing information synchronization between a fh»t 
device and a second device of claim 17, wherein the updated change counter is 

received in a confirmfrtfon message frnm tfa fipgf Antahstoe* 

19. The system for optimizing information synchronization between a first 
5 device and a second device of claim 18, wherein the confirmation message further 

includes a Unique Identifier (UID) of a record of the first database and a status of the 
database update command* 

20. Tha system fhroptfrnraTig infirwma+i fty^frr^fliirgtion between a, first 
device and a second device of claim 1 7, wherem the processmg condition comprises 

10 at least one of raiCCCwfhl COm^eticm of fee database! update ftntrnnsmd ^ , . t w j fop 

of the database update command, 

21. TIi£ ky&Usm £u£ optimizing information synchronization between a first 
device and a second device of claim 17, wherein the synchronization engine updates 
a second change counter stored at the synchronization engine in accordance with Uxe 

15 received updated change counter from the first database. 

22. The system for optimizing mfo^^ 

device and a second device of claim 21, wherein the synchronization engine submits 
the second change counter to the first database in response to initiation of a 
synchronization procedure, and wh&ein the first riatnhmsg transfers to the 
20 synchronization engine entries of the charjge log occurring after the submitted second 
change counter, tha entries of tfhe change frrosferTC^ *P th? syncfar Pfri Tati PD c^gfr 1 ^ 
with oldest entries first. 

23* The system for optimizing information synchronization between a first 
device and a second device of claim 22, wherein the synchronization engine processes 
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the transferred entries of the change log wHh the oldest entries first, and wherein the 
synchronization engine updates the second change counter after each entry is 
processed 

24. The system for optimfring information synchfftiriratkm between a first 
5 device and a second device of claim 1 7, wherein the synchronization engine comprise 

a software tnodnle adapted to perform database synchramzation functions, 

25. A mff t hfld for change fog handling far 

use in information 

syzzchzonizatioa between a first device end a second device, the method comprising 
die steps oft 

10 submitting to the fizst device a chaz^ge counter value stored at die second 

device in response to initiation of a syncfarouzatioa procedure; 

the first device returning entries 
eatrita* Iiaving a change counter greaier than the submitted change cotmier value, tae 
first device retaining the entries of the change log in increasing change counter orde^ 

15 and 

the second device processing the returned entries of the change log in 
increasing change counter order. 

26. The method fur o ptimi zing change log h a n rifrig fa 
synchronization between a fizst device and a second device of claim 25, further 

20 comprising the step of updating the change counter value stored at the second device 
after each entry of the returned change log is processed. 

27. The method for optimizing changfl log h*t*lHng for use in information 
synchronization between a first device and a second device of claim 26, further 
comprising the steps of; 
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suhmitting to (be first device the updated change counter value in response to 
an error condition detected at the second device; and 

the first device returning entries of the change log having a change counter 
greater than the submitted updated change counter value, the first device returning the 
5 entries of the change log in increasing change counter order* 
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